The Universal Mobile Telecommunication System (UMTS) is one of the third generation mobile communication technologies designed to succeed GSM. 3GPP Long Term Evolution (LTE) is a project within the 3rd Generation Partnership Project (3GPP) to improve the UMTS standard to cope with future requirements in terms of improved services such as higher data rates, improved efficiency, lowered costs etc. The Universal Terrestrial Radio Access Network (UTRAN) is the radio access network of a UMTS system and evolved UTRAN (E-UTRAN) is the radio access network of an LTE system. An E-UTRAN is connected to a mobile core network (CN) which is referred to as the Evolved Packet Core (EPC), also called System Architecture Evolution (SAE) network. The E-UTRAN and the EPC together with additional nodes, such as the Home Subscriber Server (HSS) form the Evolved Packet System (EPS), also known as the SAE/LTE network.
An SAE/LTE network architecture is illustrated in FIG. 1. The network typically comprises user equipments (UE) 150 wirelessly connected to radio base stations (RBS) 100, commonly referred to as eNodeBs (eNB). The eNB 100 serves an area referred to as a macro cell 110. In an E-UTRAN it is also possible to have a radio base station providing home or small area coverage for a limited number of user equipments. This radio base station is in 3GPP and in this document, referred to as a Home E-UTRAN NodeB 120 (HeNB). Other names used for this type of radio base station are LTE Home Access Point (LTE HAP) and LTE Femto Access Point (LTE FAP). The HeNB 120 provides the same service for the end users as an ordinary eNB 100. The coverage provided by a HeNB is in this document called a femto cell 130.
Since the current assumption in 3GPP standardization is that the X2 interface is not used with HeNBs, the X2 interface 140 is only shown between eNBs 100 in FIG. 1. All eNBs 100 are connected to the CN 160 via the S1 interface 170 using some kind of IP based transmission. The HeNBs 120 are connected to the CN 160 via a HeNB concentrator node, also referred to as a HeNB gateway 180 (HeNB GW). The S1 interface 170 is used between the HeNBs 120 and the HeNB GW 180 as well as between the HeNB GW 180 and the CN 160. A HeNB 120 would, in most cases, use the end user's already existing broadband connection (e.g. xDSL or cable) to achieve connectivity to the HeNB GW/CN 160.
One of the main drivers of the concept of providing wireless local access through a HeNB is to be bale to provide cheaper call or transaction rates when connected via an HeNB compared to when connected via an eNB.
A mobile network may have up to one million HeNBs. The CN control nodes interfacing the eNBs are referred to as Mobility Management Entities (MME) in SAE/LTE. The MMEs will not be able to handle such a large amount of HeNBs, as it is not reasonable for an MME to handle the load for that many S1 control parts (S1-MME). One purpose of the HeNB GW is thus to conceal the large number of HeNBs from the CN perspective. The CN will perceive the HeNB GW as one eNB with many cells, and the HeNB GW will act as an eNB proxy for all the HeNBs that are connected to the HeNB GW. The HeNB will perceive the HeNB GW as a CN node.
MME nodes are commonly grouped in MME pools. FIG. 2 illustrates an eNB 240 connected to an MME pool 210, comprising four MME nodes 220. The eNB 240 has S1 interfaces 260 to all members in an MME pool 210. Each MME 220 has a unique identity, called the Globally Unique MME Identity (GUMMEI), that is conveyed to the eNB 240 when the S1 interface is established. When a UE 250 attaches to the network and to an MME 220, it is allocated an identity called the Globally Unique Temporary Identity (GUTI). A GUTI consists of two parts, one part that identifies the MME which allocated the GUTI and which holds the UE context, and one part which identifies the UE within the MME. The part that identifies the MME is a GUMMEI, which in turn consists of a Public Land Mobile Network identity (PLMN ID), an MME group identity (MMEGI) which identifies the MME pool and an MME code (MMEC) which identifies the MME within the pool. The part of the GUTI that identifies the UE within the MME is called M-Temporary Mobile Subscriber Identity (TMSI). The combination of MMEC and M-TMSI is denoted S-TMSI. The S-TMSI is used for identification of the UE in situations where the PLMN ID and MMEGI are known.
In SAE/LTE, the tracking area (TA) concept replaces the UMTS routing area/location area. A UE in idle state is typically not transmitting or receiving any packets. As the UE is not in active communication with an eNB, its location may not be exactly known. A TA represents an area in which the UE was last registered, the area corresponding to one or multiple eNBs, and it is necessary to page the UE in the TA to locate the UE in a particular cell. A TA update (TAU) is generated when the UE crosses the boundary from one TA to another TA. To decrease the CN signaling, a UE can be assigned with more than one TA in its TA list. If one UE is assigned multiple TAs, the UE does not need to perform TAUs when it crosses the boundaries between assigned TAs, but as soon as the UE detects a TA identity (TAI) that is not in its TA list, a TAU is performed.
When a UE accesses an eNB to establish a Radio Resource Control (RRC) signaling connection, it identifies itself with the S-TMSI in the RRCConnectionRequest message, if the TAI of current cell is included in the UE's TAI list, i.e. if the UE is registered in the current TA. Otherwise the UE uses a random identity in the RRCConnectionRequest message. If the UE provides the S-TMSI, the eNB can use the MMEC part of the S-TMSI to figure out which MME that holds the UE context. The UE may also, e.g. when the UE is not registered in the current TA, indicate the MME in which it is registered by providing the GUMMEI of that MME in the RRCConnectionSetupComplete message, which concludes the RRC connection establishment procedure. When a UE accesses the eNB, for example to perform a TAU, the UE normally conveys its allocated GUTI in the TAU Request. The TAU request is a so called Non-Access Stratum (NAS) message, meaning that the message is sent transparently through the RBS. If the eNB cannot determine which MME the UE is registered in, or if the UE's registered MME belongs to an MME pool to which the eNB is not connected, the eNB selects an MME more or less at random, e.g. using a weighted round-robin algorithm.
FIG. 3 illustrates schematically an intra-MME load balancing procedure in a sequence diagram. A load balancing procedure may be needed to off-load an MME, e.g. for node maintenance reasons or because an MME in a pool is overloaded for some reason. The load balancing is achieved by performing a TAU according to the following procedure. The procedure's starting point is that a UE 320 has an active connection 301. An S1 connection has been established to an MME 340 and the UE 320 is registered in the MME 340. When the MME 340 decides to off-load for some reason, as in step 302, the MME 340 releases the UE 320 and indicates a specific load balancing cause for the release. More precisely, the MME 340 sends an S1AP UE CONTEXT RELEASE COMMAND message 303 to the eNB 330 with the cause information element set to ‘load balancing TAU required’. The eNB 330 releases the UE's RRC connection by sending an RRCConnectionRelease message 304 to the UE 320 with the releaseCause set to ‘load balancing TAU required’. As soon as this is done a S1AP UE CONTEXT RELEASE COMPLETE message 305 is returned to the MME 340 to confirm the connection release. The UE then initiates the establishment of a new RRC connection, for the purpose of performing the required load balancing TAU, by sending an RRCConnectionRequest 306 to the eNB 330, without including the S-TMSI, and with the establishmentCause set to a value indicating that the RRC connection is established for load balancing reasons. The eNB 330 responds with an RRCConnectionSetup message 307, and the UE 320 concludes the RRC connection establishment by sending an RRCConnectionSetupComplete message to the eNB 330, without including the GUMMEI of the MME in which the UE was registered. When a radio link is established due to load balancing, the eNB 330 thus knows that the establishment is due to load balancing, and will select an MME according to some default selection algorithm, as shown in step 309. As the eNB 330 does not know the identity of the previously used MME (neither the S-TMSI nor the GUMMEI is available), this MME cannot be excluded in the selection which means that it is still possible that the eNB selects the MME that needs to be off-loaded. The probability that the NAS TAU Request in the S1AP INITIAL UE MESSAGE 310 is sent to another MME 350 than the one previously used for this UE 320, depends on the number of MMEs in the pool. A UE context is created in the newly selected MME 350 when the TAU procedure continues 311.
FIG. 4 illustrates an example of an MME pool 410 with four MMEs 420 and a HeNB GW 430 connected to the MMEs 420. A number of HeNBs 440 covering a femto-cell 450 each within the macro-cells 460, are connected to the HeNB GW 430. Each HeNB 440 will only have one S1 interface 470 to the allocated HeNB GW 430, and the HeNB GW 430 is the entity that has multiple S1 interfaces 480 to the different MMEs 420 in a pool 410. The HeNB GW 430 will thus handle the selection of the MME 420 to use for a UE 490. The HeNB GW may base its MME selection on information acquired by snooping S1AP signaling messages on the S1 interface. Hence, the HeNB GW will select the MME based on the S-TMSI, which in most cases is included in the S1AP INITIAL UE MESSAGE message. At that point the HeNB GW also stores the identity of the eNB UE S1AP and associates it with a reference to the selected MME in a mapping table for the current S1 connections. For subsequent uplink S1AP messages, the HeNB GW identifies the correct MME by matching the identity of the eNB UE S1AP of the message with its stored mappings. If no information about how to select an MME is provided in an S1AP message, the HeNB GW selects the MME according to some default algorithm, e.g. weighted round-robin, just as described above for eNBs.
In the conventional MME load balancing procedure, as described above with reference to FIG. 3, the released UE establishes a radio link, by sending an RRCConnectionRequest to the eNB with establishment cause load balancing indicated and without including the S-TMSI. The UE also excludes the GUMMEI from the RRCConnectionSetupComplete message sent to the eNB. This procedure will not provide the wanted MME off-loading in a system with a HeNB GW (see FIG. 4), since the HeNB GW does not notice the radio link establishment handled in the HeNB, as the RRC signaling is terminated in the HeNB. The HeNB GW bases its MME selection on information in S1AP signaling messages on the S1 interface, as described above. However, neither the load balancing trigger information (i.e. the establishment cause) nor any identity of the registered MME (i.e. the MMEC in the S-TMSI) is included in the S1AP INITIAL UE MESSAGE message. Hence, the HeNB GW will, when applying the conventional load balancing procedure, select the MME according to some default algorithm, e.g. weighted round robin. In the presence of load balancing (i.e. an MME to be off-loaded) this MME selection procedure is suboptimal, since the HeNB GW will sometimes select the MME to be off-loaded, thereby increasing the load on the MME and thus counteracting the purpose of the load balancing procedure (the smaller MME pool the more frequently this problem will occur). This will in turn result in that MMEs and MME pools will function sub-optimally when a HeNB GW is connected, and this will affect not only UEs connected via HeNBs, but also UEs connected via macro layer eNBs.
Thus it still presents a problem to enable load balancing of core network control nodes in networks with RBS GWs.